Industry increasingly depends upon highly automated data acquisition and control systems to ensure that industrial processes are run efficiently, safely and reliably while lowering their overall production costs. Data acquisition begins when a number of sensors measure aspects of an industrial process and periodically report their measurements back to a data collection and control system. Such measurements come in a wide variety of forms. By way of example the measurements produced by a sensor/recorder include: a temperature, a pressure, a pH, a mass/volume flow of material, a tallied inventory of packages waiting in a shipping line, or a photograph of a room in a factory. Often sophisticated process management and control software examines the incoming data, produces status reports, and, in many cases, responds by sending commands to actuators/controllers that adjust the operation of at least a portion of the industrial process. The data produced by the sensors also allow an operator to perform a number of supervisory tasks including: tailor the process (e.g., specify new set points) in response to varying external conditions (including costs of raw materials), detect an inefficient/non-optimal operating condition and/or impending equipment failure, and take remedial actions such as adjust a valve position, or even move equipment into and out of service as required.
Typical industrial processes today are extremely complex and comprise many intelligent devices such as transmitters, positioners, motor drives, limit switches and other communication enabled devices. By way of example, it is not unheard of to have thousands of sensors and control elements (e.g., valve actuators) monitoring/controlling aspects of a multi-stage process within an industrial plant. As field devices have become more advanced over time, the process of setting up field devices for use in particular installations has also increased in complexity.
In previous generations of industrial process control equipment, and more particularly field devices, transmitters and positioners were comparatively simple components. Before the introduction of digital (intelligent) transmitters, setup activities associated with a field device were relatively simple. Industry standards like 3-15 psi for pneumatic instruments or 4-20 ma for electronic instruments allowed a degree of interoperability that minimized setup and configuration of analog transmitters.
More contemporary field devices that include digital data transmitting capabilities and on-device digital processors, referred to generally as “intelligent” field devices, require significantly more configuration effort when setting up a new field device. During configuration a set of parameters are set, within the new device, at either a device level (HART, PROFIBUS, FoxCOM, DeviceNet) or a block level within the device (FOUNDATION™ fieldbus).
Lifetime management of complex, intelligent devices requires any user performing any one of a variety of lifetime activities to possess considerable knowledge of the specific device that is being managed. In view of this need, a field device tool (FDT) standard was created that defines a set of interfaces for providing device-specific field device management user interfaces for a variety of devices via a set of device-specific add-on components.
A known FDT architecture comprises a frame application, device DTMs, and DTMs for communications devices (Comm DTMs). The FDT frame application implements FDT-compliant interfaces for DTMs to enable management of a variety of field device types, operating under a variety of protocols. The frame application (Platform) and DTMs, when combined, provide a set of graphical user interfaces (GUIs) that abstract specific implementation details of particular systems and devices thereby rendering differences between their associated protocols transparent to higher level applications built on top of the FDT architecture. Examples of such abstracted implementation details include: physical interfaces connecting to devices, persistent data storage, system management, and locations and types for device parameters.
In addition to the frame application, the FDT architecture, by way of example, also includes a communication device type manager (Comm DTM), a frame application, and device DTM. A Comm DTM performs the parameterization of communication devices such as Profibus-interface boards, Hart Modems or Gateways from Ethernet to Profibus. The Comm DTMs define a standard communications interface (e.g., Set, Get, etc.) for accessing data within online devices (e.g., Fieldbus devices) using a particular communications protocol.
Device DTMs, in general, are the drivers for lifetime management of field devices. Known device-specific DTMs encapsulate the device-specific data and functions such as the device structure, its communication capabilities, and internal dependencies. Device DTMs can also specify a graphic interface for presenting, for example, a configuration interface for an associated field device. The device DTMs provide a standardized set of interfaces to device data within field devices. Device DTMs provide/support, for example, visualization of a device status, analysis, calibration, diagnostics, and data access with regard to devices with which the device DTMs are associated. Device DTMs plug into the Frame Application and become the high-level interface for the devices. Device DTMs communicate with their associated devices through standardized interface methods supported by Comm DTMs.
The following is a general example of a setup embodying the FDT architecture. A field device is mounted to a fieldbus. However, the device is not ranged out in the field. Instead, the operator, via a workstation, installs device DTM software on a computer executing the frame application that serves as the host of the DTM. Next, the Comm DTM for communicating with the field device is installed on the computer system having the DTM and frame application. The channel associated with the Comm DTM supports communications to/from the fieldbus. A pointer to the main interface the channel is passed to the device DTM. At this point the device DTM is able to speak to the field device through the channel according to the protocol specified by the channel using specified FDT interfaces.
In the above-described example, the device DTM is pre-defined for a particular device type. As such, the DTM cannot be used for other types of devices. Furthermore, providing specific DTMs for particular device types leads to a variety of vendor and device type-specific user interfaces. A known DTM development environment developed by CodeWrights GmbH implements a tool which allows a developer to create device-specific DTMs using HART Communication Foundation Device Description (DD) files as a starting point. However, the known DTM development tool requires expert programming knowledge to fully resolve and create the user interface. In the known DTM development environment DTMs cannot be created without a user first providing programming input.